Some Cosmiq dive computers appear to produce dive profiles where the
last part (or even the entire profile) is filled with samples containing
only 0xFF bytes. Trying to interprete those bytes as a valid sample
results in depth and temperature values that are clearly invalid.

As a workaround, ignore such samples.

So far this error didn't cause any problems because the macro is only
used with a minor value of zero.

In recent OSTC 4/5 firmware versions, the data format gained support for
several new events:

 - Compass heading (v1.6.9)
 - GNSS position (v1.7.0)
 - Scrubber state (v1.7.2)

Since events are located before the extended sample data, the presence
of unsupported events is problematic. That's because the size of the
event isn't known and thus the corresponding bytes can't be skipped
correctly. Instead, those bytes will get interpreted as the next event
or as the extended sample data, resulting in some bogus values. This
problem is limited to the current sample only, because the total length
of the entire sample is available in the data.

The GNSS support isn't enabled in all firmware builds yet and a fixed
dummy location can be reported for testing:

   Latitude:   8.99
   Longitude: 47.77

Ignore these dummy locations because they are useless for the end-user.

The log version will be needed internally for features that are only
available since a certain version.

In the latest data format (v1.9), a timezone offset has been added to
address the problem with the date/time decoding mentioned earlier in
commit cc70d7a.

Prepare the code to handle response packets with a size that is not
fixed anymore. An extra output parameter is added to report the actual
size back to the caller.

In bluetooth protocol v1.30, the length of the CMD_GET_STATUS response
increased from 20 to 36 bytes. Increase the size of the buffer and
update the code to support both lengths.

Update the list of packages before installing new packages. This avoids
"404 Not Found" errors when packages on the server have been replaced
with newer versions, but the local package cache still refers to the old
version.

After Github updated the macos-latest image to macOS 15 (with Xcode 16),
linking fails with the error:

  ld: Shared cache eligible dylib cannot link to ineligible dylib
  '/opt/homebrew/opt/libusb/lib/libusb-1.0.0.dylib'.  Remove link to
  ineligible dylib, fix its eligibility, or opt out of the shared cache
  using the build setting 'LD_SHARED_CACHE_ELIGIBLE=NO' (or linker flag
  '-not_for_dyld_shared_cache')

The earlier macOS 14 image (with Xcode 15.4) already issued a warning:

  ld: warning: invalid -install_name
  (/opt/homebrew/opt/libusb/lib/libusb-1.0.0.dylib) in dependent dylib
  (/opt/homebrew/Cellar/libusb/1.0.29/lib/libusb-1.0.dylib).
  Dylibs/frameworks which might go in dyld shared cache cannot link with
  dylibs that won't be in the shared cache

This problem appears to be caused by running the configure script with
the --prefix=/usr option. Remove this option and use the default
/usr/local prefix instead of enabling some obscure linker option.

For consistency, the prefix option is removed from all build targets.

The Puck Pro EZ re-uses the same model number as the Puck 4. Only the
bluetooth device name appears to be different.

The Puck Pro Ultra re-uses the same model number as the Puck 4. Only the
bluetooth device name appears to be different.

The Quad 2 uses the Genius/Sirius variant of the protocol, with a new
model number and bluetooth device name.

The snprintf functions use the size_t datatype and therefore the
platform header should include the stddef.h header.

Each dive should at least contain a complete header. Any smaller size
would result in a buffer overflow error in the remainder of the code.

The Seac data format uses fixed size records (of 64 bytes) for both the
header and sample data. Each record contains a checksum, but also a
record type and record ID. Add a common helper function to validate all
this information.

When the dive computer battery voltage is too low, the external memory
read/write operations are not performed, which can result in corrupt
records with an incorrect checksum. The current code considers such
checksum errors as a fatal error and aborts the download. This prevents
the user from downloading any older dives.

However, during the download the contents of the header isn't really
needed, except for two cases:

 - To determine the length of the most recent dive and calculate the
   end-of-profile pointer.

 - To detect and discard padding bytes at the end of each dive.

In both cases, there is a reasonable fallback possible whenever the
header checksum is invalid and the contents of the header can't be
trusted.

In the parser, checksum errors are still treated as fatal errors.

Previously, the date/time information in the dive header was used as the
dive fingerprint. In order to decide which dives need to be downloaded,
this choice requires downloading the header of each dive during the
first pass of the download. When the entire dive is downloaded in the
second pass, these dive headers are downloaded a second time.

Using the dive number as the fingerprint can eliminate this first
download of the dive headers. That's possible because the range of
available dive numbers is communicated earlier by the dive computer and
thus the fingerprint (dive number of the most recent dive) can be
applied immediately.

When the dive computer doesn't accept the access code, it responds with
error code 13 and displays a new PIN on the screen. Update the logic to
recognize this error code and automatically ask the user for the PIN and
request a new access code.

The Shearwater Avelo mode introduced a new dive mode and sample type.
This new Avelo specific sample shares most of its structure with the
traditional sample. The changed fields are mainly the ones related to
tank T2 and CCR diving (e.g. status bits, O2 sensors, setpoint, etc).

Signed-off-by: Michael Keller <github@ike.ch>